Video Aware Traffic Management

ABSTRACT

A receiver for generating an video output from a stream of data packets includes circuitry for decoding the stream of packets into a video signal, circuitry for generating video frames from the video signal, circuitry for detecting whether a missing packet is associated with a video frame of a first type and circuitry for selectively requesting retransmission of a missing packet responsive to the detecting circuitry. The decoding circuitry further comprises circuitry for concealing errors using error recovery without requesting retransmission due to missing frames of the first type

CROSS-REFERENCE TO RELATED APPLICATION

The present U.S. Utility Patent Application claims priority pursuant to35 U.S.C. §120, as a divisional, to U.S. Utility patent application Ser.No. 11/337,372, entitled “Video Aware Traffic Management,” (AttorneyDocket No. 139444), filed Jan. 23, 2006, pending, which is herebyincorporated herein by reference in its entirety and made part of thepresent U.S. Utility Patent Application for all purposes

STATEMENT OF FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

The U.S. Government has a paid-up license in this invention and theright in limited circumstances to require the patent owner to licenseothers on reasonable terms as provided for by the terms of Award No.70NANB3H3053 awarded by National Institute of Standards and Technology.

BACKGROUND OF THE INVENTION

1. Technical Field

This invention relates in general to network communications and, moreparticularly, to a method and apparatus for discarding packets.

2. Description of the Related Art

In a digital information delivery network, between a source device and adestination device, packets of data may be lost for a variety ofreasons. Some packets are randomly lost due to uncontrollable errors—forexample, errors caused by noise on a transmission line, synchronizationissues, etc. Some packets are lost due to congestion, i.e., it is notpossible for a network element to transmit all received packets in atimely manner. Current discard mechanisms for IP QoS (quality ofservice) algorithms implement random selection schemes to determinewhich packets to discard without regard to the relative effect on theeventual output.

For some data transfer protocols, missing packets cause the destinationdevice to request a retransmission of the missing information. This isnot very feasible, however, in a network that has multicasting ofreal-time streams such as audio or video. Normally, there will not beenough time available for requesting and receiving the retransmittedpackets, unless buffers at the destination device are very large.

When an expected packet in a packet stream is not received at thedestination device, the destination device waits for a certain amount oftime before declaring a packet as lost. Once a packet is declared aslost, some decoders may request retransmission, other decoders maycorrect the problem to the extent possible by error concealmenttechniques. Error concealment techniques will in most cases result indegradation of output quality and are incapable of correcting someerrors; further, the degree of the output error will be differentdepending upon the type of data in the lost packet, some of which willbe more difficult to conceal than others. Thus, if packets must bediscarded, some types of packets will be better candidates fordiscarding than others.

Accordingly, there is a need for a method and apparatus for identifyingand discarding packets to minimize output errors.

BRIEF SUMMARY OF THE INVENTION

In a first aspect of the present invention, a receiver for generating anvideo output from a stream of data packets comprises circuitry forgenerating video frames from the packets and circuitry for decoding thestream of packets into a video signal, where the decoding circuitryincludes circuitry for concealing errors due to missing frames of afirst type. When a missing packet is detected, the receiver selectivelyconceals the error or requests retransmission, based on whether themissing packet is of said first type.

This aspect of the present invention provides for superior receivingperformance by concealing errors due to missing or corrupt low priorityvideo frames and requesting retransmission only when high priority videoframes are missing or corrupt.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

For a more complete understanding of the present invention, and theadvantages thereof, reference is now made to the following descriptionstaken in conjunction with the accompanying drawings, in which:

FIG. 1 illustrates a block diagram of a IP video delivery system;

FIG. 2 illustrates a block diagram of a multiplexer of FIG. 1;

FIG. 3 illustrates how congestion can occur at the multiplexer becauseof aggregated data rates can exceed expected average aggregated datarates;

FIG. 4 illustrates a block diagram of a first embodiment of amultiplexer;

FIG. 5 illustrates a diagram of a fragmented video frame;

FIG. 6 illustrates a flow chart describing operation of queue entrylogic for the multiplexer of FIG. 4;

FIG. 7 illustrates a flow chart describing operation of the dequeuelogic for the multiplexer of FIG. 4;

FIG. 8 illustrates a flow chart describing operation of channel changelogic for the multiplexer of FIG. 4;

FIG. 9 illustrates a block diagram of a second embodiment of amultiplexer;

FIG. 10 illustrates a flow chart describing the operation of an enqueuemicroblock for the multiplexer of FIG. 9;

FIG. 11 illustrates a flow chart describing the operation of an dequeuemicroblock for the multiplexer of FIG. 9;

FIG. 12 illustrates a flow chart describing the operation of an channelchange logic for the multiplexer of FIG. 9;

FIGS. 13 through 21 illustrate an example of the operation of themultiplexer of FIG. 9;

FIG. 22 illustrates a state diagram showing operation for a receiverthat selectively corrects errors by requesting retransmission or byerror recovery techniques.

DETAILED DESCRIPTION OF THE INVENTION

The present invention is best understood in relation to FIGS. 1-22 ofthe drawings, like numerals being used for like elements of the variousdrawings.

FIG. 1 shows a block diagram of an IP video network 10 for sending videoprogramming to a site 12. Sources (such as video head ends, or VHEs) 20provide the programming by streaming video information in packets. Thepackets are ultimately received by one or more IP video receivers 22 atthe site 12. The IP video receivers 22 translate the video packets tovideo for video monitors 24. To get to the IP video receivers 22, thedata must pass through a public/private network 26 which may include aplurality of routers, including edge router 28. The output of edgerouter 28 is received by multiplexer 30 (which could be, for example, aDSLAM access element), where the data for multiple video channels ismultiplexed onto twisted pair lines 31. A modem 32 (such as a DSL modem)on the user site communicates between the multiplexer 30 and the IPvideo receivers 22 through on-site router 34.

In operation, the VHE sources 20 stream video information to the IPvideo receivers 22. For live video broadcasts, such as a live televisionsignal, the video data is typically sent as a multicast transmission.For on-demand video, unicast transmission may be used. At the receiverside, on-demand video generally has a longer buffer, since the delayfrom source 20 to viewing is not important as broadcast video serversand, thus, on-demand video has a lower priority than live broadcastvideo services. The site 12 may have several IP video receivers 22 eachreceiving multiple streams of programming. For example, each IP videoreceiver 22 could receive two video data streams. If there were three IPvideo receivers 22 in the site 12, and each receiver 22 was receivingtwo video streams, then the link 31 between the multiplexer 30 and themodem 32 would be carrying video packets for six different data streams.

Modern day video protocols compress the video stream by periodicallysending a full frame (compressed) of video data, followed bydifferential frames which indicate the changes between frames, ratherthan the frame itself. Accordingly, a scene which has a rapidly changingimage will require a higher bandwidth than a frame that is relativelystill. The total available bandwidth between the video heads 20 and theIP receivers 22 for a site 12 is generally fixed by the bandwidth oflink 31, in view of the technology used by the multiplexer 30 and modem32.

With a fixed bandwidth in which to transfer all packets for all datastreams for a site 12, the number of data streams supported by the link31 is determined by an average bandwidth for each received channel (link31 can be carrying other data traffic such as Internet traffic, whichhas a lower priority than the live video data streams (lowest priority)and voice (VOIP—voice over Internet protocol, which generally has thehighest priority). However, the data rates for the separate N data flowsare not constant. At times, multiple channels may be simultaneouslyusing more than their average bandwidth, resulting in congestion on link31.

FIG. 2 illustrates a block diagram of the multiplexer 30 supporting Ndifferent data streams. For a system designed to provide viewing up totwo data streams over three receivers 22, N would equal six. An inputstage 40 receives various video streams and forwards packets to a FIFO(first in, first out) memories 42 (alternatively, multiple FIFOs couldbe used for respective data streams). An output stage 44 multiplexespackets from the FIFO memory 42 onto the link 31 (via DSL schedulingcircuitry, not shown). At the site 12, router 34 directs packets to theproper receiver 22. Traffic Management System 46 controls themultiplexing of the packets from memories 42 onto the link 31, asdescribed in greater detail below.

The congestion problem is illustrated in FIG. 3. When the combined datarates from the N sources exceed the capacity of the link 31 and thecapacity of the multiplexer 30 to buffer the overage in its FIFOmemories 42, the traffic management system 46 must make intelligentdecisions about which packets to discard to minimize any adverse effectson data service to the end user. The situation is illustrated in FIG. 3,which employs only two data sources (N=2). In FIG. 3, data packets comefrom Source A and Source B. Each source implements a policy to providedata at a known average rate. The data from the two sources must bemerged onto link 31, which has a capacity to accommodate the combinedaverage data rates. Limited buffering is available from the FIFOmemories 42; however, it is desirable to keep the FIFO memories as smallas possible; otherwise a noticeable delay will occur when live videochannels are switched. When the combined data rates from the sourcesexceeds the average for too long, the capacity to buffer the excess datais exceeded, and some packets must be dropped. Even if the multiplexer30 has the memory capacity to buffer additional packets, it may need todrop packets because of timing considerations associated with its FIFO42. For example, a multiplexer 30 may have a requirement that allpackets will be sent within 200 ms of receiving that packet. If thecondition cannot be met for an incoming packet, the multiplexer willeither need to not place the incoming packet in the FIFO 42 or droppackets already in the FIFO 42.

In operation, the multiplexer 30 is designed to minimize the effect ofdropping packets. A critical aspect of the problem is that all packetsare time-critical. For each data stream all packets are generated on asingle server (VHE 20). Once generated, each packet has a strict “useby” time. A packet that becomes stale in transit to the end user becomesunusable. To conserve shared link bandwidth, stale packets must bediscarded without being transmitted over the link 31.

In operation, multiplexer 30 conforms to a policy that requires theminimum degradation of service to the end user when packets arediscarded. This goal is accomplished in two basic ways: (1) themultiplexer 30 discards the minimum amount of data necessary to avoidcongestion and (2) the multiplexer 30 makes use of a priority scheme toensure the least useful packets are preferentially discarded.

FIG. 4 illustrates a more detailed block diagram of the multiplexer 30of FIG. 2, showing an embodiment which makes use of packets containingpriority indicators. It is assumed that the priority indicators aregenerated by the video head end 20. For the illustrated embodiment, atwo bit priority (four possible priority values) is used with “00”binary being the lowest priority and “11” binary being the highestpriority.

The traffic management system 46 is split into queue entry logic 50,dequeue logic 52, channel change logic 54 and forward prediction logic56. Each priority level has a threshold level in the FIFO 42, i.e., aP00 (“Priority 00”) threshold, a P01 threshold, a P10 threshold and aP11 threshold. Additionally, there is an Initial Hold-off threshold.When a threshold level is exceeded, a flag is set (a “P00 FG” notationis used to represent the flag from priority “00”). It is assumed thatthe thresholds are based on a time-to-dequeue statistic. In other words,if the P00 threshold is set to 50 msec, it is exceeded if there arepackets in the queue which will not be dequeued within 50 msec. Sincethere may be packets in the FIFO 42 that will not be transmitted, thephysical location of a packet may not be indicative of whether athreshold level has been exceeded.

In the illustrated embodiment, a single FIFO 42 is used for multiplechannels (multiple data streams). In the preferred embodiment, the lowpriority flags, P00 FG and P01 FG, are maintained on a global basis,i.e., one flag is used to indicate that a packet has exceeded athreshold, regardless of the channel associated with that packet. Thehigher priority flags, P10 FG and P11 FG, are maintained on a perchannel basis; for example, if a packet on channel “1” exceeds the “10”threshold, the P10 flag is set for channel “1”, but not for channel “2”(in the illustrated embodiment, only two channels are shown, although anactual embodiment may support more channels).

For background purposes, FIG. 5 illustrates the association betweenvideo frames and packets. Throughout the network 10, information istypically passed as Ethernet packets 58. Some video frames will belarger than an Ethernet packet 58 and, hence, must be fragmented intomultiple packets. The receiver 22 will then group the packets back intovideo frames for decoding. In the preferred embodiment, as describedbelow, if any packet of a video frame is discarded, then surroundingEthernet frames are inspected by the traffic management system 46; forany frame in which a packet has been discarded, any remaining packetsassociated with that frame will be discarded as well, since thesepackets will have no value to the receivers 22. It should be noted thatEthernet frames occasionally are received out-of-order, and thereforethe traffic management system 46 should search a sufficient distancefrom a discarded packet to ensure that all associated Ethernet frameshave been properly inspected.

FIG. 6 illustrates a flow chart describing the operation of the queueentry logic 50. The steps in FIG. 6 indicate the operation of the queueentry logic 50 for each packet that is received. In step 60 it isdetermined whether the initial hold-off threshold has been met. Untilthe hold-off threshold is met, no packets are dropped, even if the otherpriority thresholds have been exceeded. Once the initial hold-offthreshold is met, subsequent packets will be checked to see if thepriority thresholds are exceeded. In step 62, the queue entry logic 50determines if queuing the packet in FIFO 42 will result in the prioritythreshold P00 being exceeded. If so, the P00 flag is set in step 64 andqueue entry logic 50 determines if queuing the packet in FIFO 42 willresult in the priority threshold P01 being exceeded in step 66. If theP01 threshold is not exceeded in step 66, the queue entry logic 50determines whether the packet is a P00 packet in step 68. If so, it isdiscarded in step 70.

If in step 66, the P01 threshold is exceeded, then the P01 flag is setin step 72. The queue entry logic 50 determines if queuing the packet inFIFO 42 will result in the priority threshold P10 for the associatedchannel being exceeded in step 74. If the priority threshold P10threshold for the channel is not exceeded in step 74, the queue entrylogic 50 determines whether the packet is a P00 or a P01 packet in step76. If so, it is discarded in step 70.

If in step 74, the P10 threshold is exceeded, then the P10 flag is setin step 78. Queue entry logic 50 determines if queuing the packet inFIFO 42 will result in the priority threshold P11 for the associatedchannel being exceeded in step 80. If the priority threshold P11threshold for the channel is not exceeded in step 80, the queue entrylogic 50 determines whether the packet is a P00, a P01 or a P10 packetin step 82. If so, it is discarded in step 70.

If in step 80, the P11 threshold is exceeded, then the P11 flag is setin step 84. Queue entry logic 50 determines whether the FIFO 42 is fullin step 86. If so, the packet is discarded in step 70. If the FIFO isnot full, then the queue entry logic 50 determines whether the packet isa P11 packet in step 88. If not, it is discarded in step 70.

If the P00 threshold is not exceeded in step 62 or if the packet isdetermined not to be a P00 packet in step 68, or not to be a P00/P01packet in step 76 or not to be a P00/P01/P10 packet in step 82, or isdetermined to be a P11 packet in step 88, then it is checked to see ifit is a fragment of a frame which has had packets previously discardedin step 92. If so, it is discarded in step 70; if not, it is added tothe queue in step 94.

After a packet is discarded in step 70, the queue entry logic 50determines whether it is a fragment of a larger frame in step 96. If so,the frame ID is saved in step 98 to match with other fragments from thesame frame.

It should be noted that the flags are reset upon receiving n packetsduring which the condition for setting the flag no longer exists. Thevalue n is a configurable value.

FIG. 7 illustrates flowchart describing operation of the dequeue logic52. Upon a packet extraction request from the DSL scheduler (a requestthat the next packet be sent to the DSL scheduler for transmission onlink 31), the dequeue logic 52 gets the next packet at the head of theFIFO 42 in step 100 checks to see if the next packet in line for outputfrom FIFO 42 is a packet associated with a previously discarded frame instep 102. If so, it is discarded (not output) in step 104. If not, instep 106, the dequeue logic 52 determines whether the P00 flag is set;if not, the packet is dequeued (sent to the DSL scheduler fortransmission on twisted pair lines 31) in step 108. After the packet isdequeued, there may be packets at the front of the queue which are nottransmit eligible. The dequeue logic 52 will discard these packets untilthe next transmit eligible packet appears. The dequeue logic 52 thenwaits for the next request from the DSL scheduler.

If the P00 flag is set in step 106, then the packet will be discarded ifit is a P00 packet (step 112). If the packet has a priority higher thanP00 in step 112, the dequeue logic 52 will determine whether the P01flag is set in step 114. If the P01 flag is set in step 114, then thepacket will be discarded if it is a P01 packet (step 116). If the P01flag is not set in step 114, the packet will be dequeued (step 108). Ifit is higher then a P01 packet in step 116, the dequeue logic 52 willdetermine whether the P10 flag is set (for the channel associated withthe packet) in step 118. If the P10 flag for the channel is set in step118, then the packet will be discarded if it is a P10 packet (step 120).If the P01 flag is not set in step 114, the packet will be dequeued(step 108). If the packet has a priority higher P10 packet in step 120,the dequeue logic 52 will determine whether the P11 flag is set (for thechannel associated with the packet) in step 122. If the P11 flag for thechannel is set in step 122, then the packet will be discarded. If theP11 flag is not set, the packet will be dequeued.

Referring again to FIG. 4, the channel change logic 54 speeds theprocess of discarding packets associated with a channel no longer beingwatched. FIG. 8 illustrates a flow chart describing the operation of thechannel change logic 54. If the user changes channel (and assuming thatno other user is watching the “from” channel), the old channel number(the “from” channel ID) and new channel number (the “to” channel) aresent to the channel change logic 54. Upon receiving this information,the channel change logic works with the dequeue logic 52 to removepackets associated with the “from” channel. The channel change logic 54also removes low priority packets associated with the “to” channel sincethese packets will be associated with differential frames (i.e., framesdependent upon other video frames) and therefore useless to thereceivers 22. If another receiver 22 remained tuned to the “to” channel,these packets would not be dropped.

In step 130, the next packet is taken from the head of the FIFO 42. Ifit is associated with the “from” channel in step 132, it is discarded instep 134. If it is not associated with the “from” channel, but isassociated with the “to” channel in step 136, the packet is discarded ifit is a low priority packet (P00 or P01) in step 138. If it is a highpriority packet in step 138, then the channel-change clearing process iscomplete in step 140.

Referring again to FIG. 4, the forward prediction logic 56 receivesinformation regarding upcoming packets that have not yet been received.The forward prediction logic can therefore make estimation of whenadditional space will be needed to accommodate packets of a specifiedpriority. Accordingly, the discarding functions described above can bemade prior to actual congestion occurring.

In the embodiment described above, FIFO thresholds are used to keeppackets from entering the queue based on the threshold exceeded and apriority associated with the packet. This embodiment provides a methodof passing high priority packets using a minimum amount of computationresources. A second embodiment is described below which operates in adifferent manner. When the buffer is full (i.e., when new packets willnot reach the end of the FIFO buffer within the predetermined timelimit), packets within the FIFO are marked for discard within the FIFO.When these marked packets reach the head of the FIFO, they are simplynot passed forward for transfer over link 31.

FIGS. 9-19 illustrate a second embodiment of a multiplexer 30 where theaccess network equipment can recognize video traffic in order to makedropping decisions during congested periods to help minimize the servicequality degradation. Some types of video packets are more important forthe reproduction of high quality video than other types of videopackets. The video packet discard decision is made upon video packettype and current congestion level such that least important packets(those that have the least impact on picture quality) are dropped firstand the next least important packets are dropped next, and so on.

In this embodiment, packets already in the video queue can be marked fordiscard. Discarding enqueued packets results in faster video queue spacerecovery and can contribute to faster channel change support. Thisembodiment assumes that the video data streams are generated by anencoder or video server 20 that follows a set of rules, or a protocol,for transport of compressed video content on an IP packet network. Morethan one protocol definition may be accommodated. The protocols definehow packet headers are assembled, and how video content priorityindicators are coded at the application layer. The embodiment furtherassumes that the video data transport data rate is within the rangedefined for a particular network implementation. In addition, thisembodiment assumes that a maximum packet size is defined at theapplication layer such that fragmentation at the lower layers will neverbe required. This is to ensure that every video packet entering theaccess node contains the video component priority indicators.

In FIG. 9, a per subscriber pseudo video queue (buffer) 150 includesper-priority index lists (PILs) 152 (with one priority index list 152for each priority level—in the illustrated embodiment, there are onlytwo priority levels, P0 and P1) and a forward/drop list (FDL) 154. Avideo metadata buffer 156 has entries containing the packet metadata foreach packet enqueued in the physical video packet buffer 158. The pseudovideo buffer 150, video metadata buffer 156 and physical video packetbuffer 158 are coupled between the enqueue microblock 160 and thedequeue microblock 162. The physical video buffer stores packetsidentified by the priority of the task (P0 or P1) and the data stream(channel) associated with the packet (S0 or S1). In an actualembodiment, there could be additional priority levels and more datastreams would likely be supported.

In operation, enqueue microblock 160 and dequeue microblock 162 controlthe flow of packets into and out of the multiplexer 30 and maintain thecontents of the pseudo video queue 150 and video metatdata buffer 156.As video packets are received, they are stored in the physical videobuffer 158. Each packet in the physical video buffer 158 has itsmetadata stored in an associated entry of the video metadata buffer 156.The metadata information is used for further packet processing. Ifmultiple receivers 22 are subscribed to the same channel, multiplemetadata will exist in the video metadata buffer 156 for the same videostream. The video metadata buffer 156 is preferably a FIFO queue of apredetermined finite depth that maintains the metadata in the order ofthe video packets.

When congestion is detected (i.e., the time between receiving a packetand transmitting the same packet exceeds a predetermined threshold), orif the physical video buffer 158 is full, packets within the physicalvideo buffer 158 are marked for discard (when a packet marked fordiscard reaches the front of the physical video buffer 158, it will beremoved without further transmission on the link 31). If there are nocurrently enqueued packets within the physical video buffer 158 that canbe dropped to make room of the incoming packet, then the incoming packetwill be dropped without enqueue.

The pseudo video buffer 150 is used to identify and mark packets fordiscard. The pseudo video buffer 150 uses circular buffers as its maindata structure with head and tail pointers such that a new buffer entryis added at the tail and buffer entries are removed from the head. Asshown below, this circular list data structure provides a simplemechanism to maintain the list.

The pseudo video buffer 150 includes a forward/drop list 154 and anindex list 152 for each priority type. Each entry in the forward/droplist 154 is associated with an entry in the video metadata buffer 156.The contents of each entry in the forward/drop list 154 is either anindicator of the data stream (either “0” or “1” in the illustratedembodiment), if the packet is to be forwarded, or a discard marker (“D”)to indicate that the associated packet is to be dropped. Each priorityindex list 152 maintains an index of packets by priority. By maintaininga separate list of packet for each priority, packets or metadata of acertain priority can be easily located for marking without scanning theentire queue.

FIG. 10 is a flow chart that illustrates the operation of the enqueuemicroblock 160. When a video packet arrives in step 170, the enqueuemicroblock 160 determines whether the physical video buffer canaccommodate the incoming packet in step 172. If so, the enqueuemicroblock 160 extracts packet information (such as priority, videostream ID, and so on) from the incoming packet and the packet isenqueued by inserting the packet's video stream ID in the forward/droplist 154 (step 174) and adds the forward/drop list index of the packetto the appropriate index list 152, depending on the priority informationfrom the metadata (step 176). In step 178, the remaining queue level(QLevel) is adjusted to account for the newly enqueued video packet.

If the buffer is congested in step 172, the enqueue microblock looks ata index list 152 associated with lower priority packets (i.e., if theincoming packet is a P1 packet, the P0 index list will be used todetermine whether there are lower priority packets in the physical videoqueue 158). If the appropriate index list 152 is empty in step 180, theincoming packet is discarded (not enqueued) in step 182. On the otherhand, if the appropriate index list 152 is not empty in step 180, thelower priority packets designated in the index list 152 are marked fordiscard in the forward/drop list 154 to create additional space in thephysical video buffer in steps 184-188. In the preferred embodiment, theenqueue process will only mark packets for discard until enough room isrecovered to enqueue the incoming packet. In step 184, a packet isidentified by an entry from the appropriate index list 152; the index inthat entry points to a corresponding entry in the forward/drop list.That entry is marked for discard (by a “D” in the illustratedembodiment) in step 186. The entry is then deleted from the index list152 and the queue level is adjusted to account for the discarded packet.Control continues at step 172, where it is determined whether the queuehas room for the incoming packet after discarding the packet. If so, theincoming packet is enqueued in steps 174-178. If more space is needed toenqueue the incoming packet, the index lists are again checked for lowerpriority packets within the queue. The process is repeated until eitherenough room is obtained by discarding lower priority packets or, if nomore room can be created, by discarding the incoming packet.

The operation of the dequeue microblock 162 is shown in FIG. 11. In step190, a send request is received by the dequeue microblock 162 from theDSL transmit scheduler. If the forward/discard list (FDL) 154 is emptyin step 192, then there are no packets to send at the current time. Onthe other hand, if the forward/discard list 154 indicates that there arepackets to sent in step 192, then the next entry in the forward discardlist 154 for the next packet to sent is dequeued in step 194, as well asthe corresponding entry from the index list 192. In step 198, if theentry from the forward/discard list indicates that the packet has beenmarked for discard, then control returns to step 192 to look at the nextpacket in the physical video buffer 158. On the other hand, if the entrydoes not indicate that the packet is not marked for discard, then themetadata for the packet is retrieved in step 200 and the packet isforwarded in step 202.

FIG. 12 illustrates a flow chart describing the operation of channelchange logic. Fast channel change support can be accomplished bydiscarding the packets in the video buffer as soon as possible that arerelated to the previous video channel to make room for new video stream.When a channel change notice is received in step 210, a scan index(scanidx) is set to the head of the forward/discard list in step 212 andthe video channel ID for the “from” channel is retrieved in step 214.The forward/discard list 154 is inspected at the scan index in step 216to see if the stream at that entry matches the “from” channel datastream ID. If so, the forward/discard list is marked for discard at theentry specified by the scan index in step 218. In step 220, thecorresponding index list entry is marked as discarded as well. In step222, the scan index is incremented to find additional packets associatedwith the “from” channel. If the scan index is incremented to the tail ofthe forward/discard list in step 224, then all such packets have beenfound; otherwise the forward/discard list is searched again in step216-220. In the event that an entry does not have a video stream ID thatmatches the “from” channel in step 216, then the scan index inincremented in step 222.

FIGS. 13-21 provide illustration of the operation of the multiplexer 30.FIG. 13 illustrates an instance of the initial state of the multiplexer30, where the physical video buffer has a buffer depth of 26, withpackets in physical video buffer 158 currently has five packets(S1/P0-length 3, S1, P0-length 6, S0/P0-length 3, S0/P1-length 6 andS1/P0-length 3). Hence the fill level of the current packets is 21,leaving a length of 5 for new packets. An incoming packet (S0/P0) with alength of 3 is received at the enqueue microblock 160.

In FIG. 14, the new packet is enqueued, since there is sufficient spacein the physical video buffer 158. The forward/discard list 154 adds thenewly enqueued packet as index “5” in the list denoting the packet asassociated with stream “0”. Likewise, index list 152 for P0 is updatedto reference the index (5) of the newly enqueued packet. An entry ismade in the video metadata buffer 156, which is associated with thepacket in the physical video buffer 158. The new buffer fill level isnow 24, since the new packet increased the level by three.

In FIG. 15, another incoming packet (S0/P1-length 6) is at the enqueuemicroblock 160. Since the packet has a length of six and the physicalvideo buffer 158 has only a length of two available, lower prioritypackets in the buffer must be marked for discard to accommodate the newpacket. As described above, the enqueue microblock looks for packets oflow priority (i.e., P0 packets) to discard. Since there are entries inthe P0 index buffer 152, there are available packets to discard.

In FIG. 16, the first packet indicated at the head of the P0 indexbuffer 152 (index 0) is marked for discard in both the index buffer 152and the forward/discard buffer 154. This packet, although marked fordeletion, remains in the physical video buffer 158; however, three unitsare added to the available length (now five units), because the packetmarked for discard will not affect the time for a new packet to move tothe front of the physical video buffer.

In FIG. 17, with five units available for a new packet and an incomingpacket with a length of six, additional packets must be discarded if theincoming packet is to be enqueued. Since there are still entries in theP0 index buffer, there are more packets to discard. Hence, the packetindicated at the head of the P0 index buffer 152 (index 3) is marked fordiscard in both the index buffer 152 and the forward/discard buffer 154.This results in an available length of eight, allowing the incomingpacket to be enqueued in physical video buffer 158. The newly enqueuedpacket is represented in the forward/discard list 154 at index 6(denoting the packet as being associated with stream “0”). Thisinformation is also added to the P1 index list 152 and the packetsmetadata is stored in the video metadata buffer 156.

In FIG. 18, the packet marked for discard at the head of the physicalvideo buffer 158 is removed. Because it will not be forwarded, its datawill simply be overwritten by the data behind it in the FIFO. This alsocauses the head of the forward/discard list 154 to rotate so that index“1” is at the front of the list.

In FIG. 19, the packet at the front of the physical video buffer 158 isforwarded to the DSL forwarding circuitry for transmission on link 31.The packet and its metadata is forwarded, and the forward/discard list154 is updated such that index “2” is moved to the head.

In FIG. 20, a channel change is initiated by the user, switching awayfrom data stream “0”. Accordingly, the enqueue microblock 160 scans theentries of the forward/discard list 154 for packets with data stream“0”, of which two are listed at index “5” and index “6”.

In FIG. 21, the two packets at indices “5” and “6” are marked fordiscard in the forward/discard list 154 and the index lists 152 forthese packets are also updated.

The embodiment of the invention described in FIGS. 9-21 presentinvention ensures that higher priority packets are delivered to thecustomer premises, if at all possible. By maintaining lists of packetsby priority level, lower priority packets can be easily found withoutscanning an entire list of packets.

In either embodiment described herein, the receivers may be faced withlost packets. FIG. 22 illustrates a state diagram showing operation of areceiver 22 that can selectively request retransmission of packet orattempt to conceal errors. In state 240, the receiver 22 is in normalmode, receiving packets, decoding the information from the packets andgenerating video output. When the receiver 22 detects a missing frame,the type of frame is detected in state 242. The frame type will dependupon the protocol; in general within a protocol, the frame type can bedetermined based on a known order of frame types set by the encodingdevice. If the missing frame is of a type that can be concealed, errorrecovery is performed in state 244. If the missing frame is of a typethat cannot be concealed, for example an I-frame or a video anchorframe, then retransmission is requested in state 246.

Although the Detailed Description of the invention has been directed tocertain exemplary embodiments, various modifications of theseembodiments, as well as alternative embodiments, will be suggested tothose skilled in the art. The invention encompasses any modifications oralternative embodiments that fall within the scope of the Claims.

1. A receiver for generating an video output from a stream of datapackets, comprising: circuitry for decoding the stream of packets into avideo signal; circuitry for generating video frames from the videosignal; circuitry for detecting whether a missing packet is associatedwith a video frame of a first type; and circuitry for selectivelyrequesting retransmission of a missing packet responsive to thedetecting circuitry; wherein said decoding circuitry further comprisescircuitry for concealing errors using error recovery without requestingretransmission due to missing frames of the first type.
 2. The receiverof claim 1 wherein the detecting circuitry further comprises circuitryfor determining a position of a video frame associated with a missingpacket within an order of received frames.
 3. The receiver of claim 1further comprising: circuitry for detecting whether a missing packet isassociated with a video frame of a second type.
 4. The receiver of claim3 wherein the second type is an I-frame or a video anchor frame.
 5. Thereceiver of claim 3 wherein the requesting retransmission circuitryfurther comprises circuitry for requesting retransmission of saidmissing packet when said missing packet is associated with a video frameof the second type.
 6. A method for generating a video output from astream of data packets in a receiver, comprising: decoding the stream ofpackets into a video signal; generating video frames from the videosignal; upon determining that a packet is missing from the stream,detecting a type of video frame associated with the missing packet andresponsive to the type, selectively: concealing errors using errorrecovery without requesting retransmission due to missing frames of afirst type; or requesting retransmission of a missing packet.
 7. Themethod of claim 6 wherein the detecting step comprises the step ofdetermining a position of a video frame associated with a missing packetwithin an order of received frames.
 8. The method of claim 6 furthercomprising: detecting whether a missing packet is associated with avideo frame of a second type.
 9. The method of claim 8 wherein thesecond type is an I-frame or a video anchor frame.
 10. The method ofclaim 8 wherein the requesting retransmission step further comprisesrequesting retransmission of said missing packet when said missingpacket is associated with a video frame of the second type.